\chapter{Implementierung und Validierung}
Wie in \ref{sec:Softwareentwurf} beschrieben, werden die einzelnen Implementierungen in separaten Projekten umgesetzt. Diese bauen ggf. aufeinander auf. So wird zunächst nur die Kommunikation mit dem LEA-6H Empfänger von u-blox realisiert. Dieses Projekt wird später bei der synchronen Datenerhebung wieder aufgegriffen und erweitert, sodass die erhobenen Zeitstempel möglichst nah am Empfang der Nachricht gesetzt werden.

\section{Kommunikation mit u-blox Empfänger}	\label{sec:Kommunikation mit u-blox Empfänger}
Als erstes Projekt wird die Kommunikation mit dem LEA-6H realisiert. Dies geschieht angelehnt an den von National Instruments unter \cite{ninmea} vorgestellten \acp{VI} und unter Verwendung des Referenzdesigns. Zunächst ist allerdings eher die Funktionalität der Kommunikation nach dem \acs{NMEA} und dem UBX-Protokoll, als die Vergabe korrekter Zeitstempel von Interesse. Daher erfolgt zunächst keine Erhebung von Zeitstempeln.


\begin{figure}[htb]
	\centering
	\includegraphics[width=0.7\linewidth]{img/ubxKommunikation-MAIN-VI-BD}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{MAIN.VI} im Projekt \texttt{Kommunikation-LEA-6h.lvproj}}		%Bildunterschrift
	\label{pic:Blockdiagramm des MAIN.VI im Projekt Kommunikation-LEA-6h.lvproj}	%Referenz zum Verlinken
\end{figure}

Wie Abbildung~\ref{pic:Blockdiagramm des MAIN.VI im Projekt Kommunikation-LEA-6h.lvproj} zeigt, entspricht das Projekt dem unter \ref{sec:Referenzdesign für die Unterprojekte} vorgestellten Referenzdesign. Die \acp{VI} \texttt{Eistellungen.vi} und \texttt{init.vi} sind hierbei beide Teil der Initialisierungsphase. 

\subsection{Initialisierungsphase}	\label{sec:Initialisierungsphase}
\subsubsection{\texttt{\textbf{Einstellungen.vi}}}	\label{sec:Einstellungen.vi}
Zunächst werden der TDMS-Speicherpfad und der \acs{COM}-Port des u-blox-Empfängers in \texttt{Einstellungen.vi} vom Nutzer festgelegt. Diese Informationen werden innerhalb des \acs{VI}s in den Referenzcluster geschrieben, sobald der Nutzer seine Eingabe beendet hat. Der Cluster enthält in diesem Projekt weiterhin nur die Referenzen der \texttt{GPS-Logging-Queue} und des \texttt{GPS-VIEW-Melder}s.


\subsubsection{\texttt{\textbf{init.vi}}}	\label{sec:init.vi}
Im \texttt{init.vi} werden als erstes die Queue und der Melder, sowie die Umgebungsvariable \texttt{STOPP} mit \texttt{FALSE} initialisiert. Daraufhin erfolgt die Konfiguration der seriellen Schnittstelle\footnote{Zum Zeitpunkt der Implementierung ist die Baudrate des LEA-6H, gemäß des NMEA 0183 Standards, auf 4800 bps eingestellt. } im \acs{SubVI} \texttt{initGPS.vi}. 
Die komplette \acs{VI}-Hierarchie zeigt Abbildung~\ref{pic:VI Hierarchie des Projekts Kommunikation-LEA-6h.lvproj}.
Als letztes wird mittels \texttt{UBX\_Kaltstart.vi} die Konfigurationsnachricht für den Hardwarereset an den LEA-6H gesendet.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/ublxKomm_ViHirarchie}	%Breite und Pfad
	\caption{VI Hierarchie des Projekts \texttt{Kommunikation-LEA-6h.lvproj}}		%Bildunterschrift
	\label{pic:VI Hierarchie des Projekts Kommunikation-LEA-6h.lvproj}	%Referenz zum Verlinken
\end{figure}

\subsubsection{\texttt{\textbf{initGPS.vi}}}	\label{sec:initGPS.vi}

Dieses \acs{VI} ist dem ersten Teil aus \texttt{Read NMEA GPS SubVI.vi} \cite{ninmea} entnommen, der beim ersten Aufruf der While-Struktur ausgeführt wird und in diesem \acs{VI} den \acs{COM}-Port initialisiert. Zur besseren Übersichtlichkeit ist dieser Progammteil als eigenständiges \acs{VI}, wie in Abbildung~\ref{pic:Blockdiagramm von initGPS-BD.vi} gezeigt, hinterlegt.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/intGPS-BD}	%Breite und Pfad
	\caption{Blockdiagramm von \texttt{initGPS-BD.vi}}		%Bildunterschrift
	\label{pic:Blockdiagramm von initGPS-BD.vi}	%Referenz zum Verlinken
\end{figure}


\subsubsection{\texttt{\textbf{UBX\_Kaltstart.vi}}}	\label{sec:UBXKaltstart.vi}
Die Realisierung des Kaltstarts ist mit etwas größerem Implementierungsaufwand verbunden, da die Umsetzung des UBX-Protokolls in \acs{LabVIEW} erforderlich ist. 
Im \texttt{UBX\_Kaltstart.vi} wird, nach Leerung des Schreib- und Lesepuffers der Schnittstelle, die Konfigurationsnachricht nach Tabelle~\ref{tab:UBX-CFG-RST Nachricht für Kaltstart} innerhalb einer \texttt{FOR}-Schleife mehrfach gesendet, sofern Bestätigungsnachricht ausblieb oder negativ ausfiel. Dabei werden standardmäßig bis zu zehn Versuche\footnote{Die Anzahl der Versuche kann durch den Programmierer allerdings über den \acs{SubVI}-Eingang \texttt{\#-Versuche (10)} programmatisch angepasst werden.} unternommen. Wie Abbildung~\ref{pic:Blockdiagramm des UBX-Kaltstart.vi} zeigt, werden Nachrichtenklasse und -\acs{ID}, sowie der Payload an das \texttt{UBX\_BefehlSenden.vi} übergeben. Die Überprüfung der Bestätigungsnachricht übernimmt danach \texttt{UBX\_ACK.vi}. Dieses \acs{VI} gibt über zwei boolsche Ausgänge den Empfang einer ACK-ACK bzw. ACK-NAK Nachricht an. Wurde das \acs{VI} ausgeführt und beide Ausgänge sind \texttt{FALSE}, so wurde entweder keine, keine der beiden erwarteten Nachrichten, oder eine Nachricht mit falscher Prüfsumme empfangen. Solange keine ACK-ACK Nachricht mit korrekter Prüfsumme empfangen wurde, bietet es sich also an die UBX-CFG Nachricht abermals zu senden. Dieses Vorgehen ist im Blockdiagramm des \texttt{UBX\_Kaltstart.vi}s, in Abbildung~\ref{pic:Blockdiagramm des UBX-Kaltstart.vi} zu sehen.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/UBX-Kaltstart-BD}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{UBX-Kaltstart.vi}}		%Bildunterschrift
	\label{pic:Blockdiagramm des UBX-Kaltstart.vi}	%Referenz zum Verlinken
\end{figure}

\subsubsection{\texttt{\textbf{UBX\_BefehlSenden.vi}}}	\label{sec:UBXBefehlSenden.vi}
Wie in Abbildung~\ref{pic:UBX protocol frame} gezeigt, besteht das UBX-Protokoll aus zwei festen Start Zeichen, ein Zeichen für die Befehlsklasse, eines für die Befehls-\acs{ID}s, zwei Byte für die Information zur Länge der Nachricht, dem Nutzdaten, dessen Größe je nach Nachrichtentyp variiert und zwei Bytes Prüfsumme. Das \texttt{UBX\_BefehlSenden.vi} nimmt diese Eingänge entgegen und führt daraufhin das Senden eines Befehls aus. Dabei werden nur Befehlsklasse, Befehls-\acs{ID} und Nutzdaten (in korrekter Länge) übergeben. Die Länge der Nutzdaten berechnet das \acs{VI} selbst und wandelt das Ergebnis in das Little Endian Format um. Für die Berechnung der Prüfsumme wird das \acs{VI} \texttt{UBX\_CHKSUM\_generate.vi} verwendet.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/UBX_BefehlSenden_BD}	%Breite und Pfad
	\caption{\texttt{UBX\_BefehlSenden.vi} Blockdiagramm}		%Bildunterschrift
	\label{pic:UBXBefehlSenden Blockdiagramm}	%Referenz zum Verlinken
\end{figure}

\subsubsection{\texttt{\textbf{UBX\_CHKSUM.vi}}}	\label{sec:UBX_CHKSUM.vi}
Die Berechnungsvorschrift für die beiden Bytes der Prüfsumme, welche aus den Bytes der Nutzdaten generiert wird, ist in diesem \acs{VI} realisiert, wie Abbildung~\ref{pic:Blockdiagramm des UBX_CHKSUM.vi} zeigt. Dabei wird der 8-bit Fletcher Algorithmus umgesetzt, welcher im \acf{TCP} Standard verwendet wird. \cite[S.~84]{ubx6} 

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.7\linewidth]{img/UBX-CHKSUM}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{UBX\_CHKSUM.vi}}		%Bildunterschrift
	\label{pic:Blockdiagramm des UBX_CHKSUM.vi}	%Referenz zum Verlinken
\end{figure}


\subsubsection{\texttt{\textbf{UBX\_ACK.vi}}}	\label{sec:UBX-ACK.vi}
Der Befehl für den Kaltstart  ist aus der Klasse der UBX-CFG Nachrichten, auf denen immer eine Bestätigung ACK-ACK bzw. ein Nicht-Bestätigung ACK-NAK folgt\cite[S.~84]{ubx6}. Wurde also der gesendete Befehl nicht vom LEA-6H bestätigt\footnote{Dies geschieht in etwa 2 von 15 Fällen.}, so muss er noch einmal gesendet werden.

Ein Empfang einer ACK-ACK Nachricht gilt nur dann als korrekt, wenn diese auch die korrekte Prüfsumme aufweist und somit selbst eine korrekte Nachricht ist. Das Empfangen einer Nachricht, inklusive der Überprüfung der Prüfsumme findet im \texttt{UBX\_readMsg.vi} statt.

Tabelle~\ref{tab:Aufbau der ACK-ACK und ACK-NAK Nachricht im UBX-Protokoll} zeigt den Aufbau der Bestätigungsnachrichten und gibt Einblick in die in Abbildung~\ref{pic:Blockdiagramm des UBX_ACK.vi} dargestellte Funktionsweise des \texttt{UBX\_ACK.vi}. Dieses wartet zunächst auf den Empfang der ACK-ACK Nachricht\footnote{Dies beeinflusst allerdings nicht, welche Nachricht wirklich empfangen wird. Der Empfang einer ACK-NAK Nachricht kann ebenso erfolgen.}. Im \texttt{UBX\_ACK.vi} wird dann die empfangene Nachricht ausgelesen. Im Payload der ACK-ACK bzw. ACK-NAK Nachricht ist die Klasse und \acs{ID} der zu bestätigenden Nachricht enthalten. Entsprechen beide der zu bestätigen Nachricht und ist die Prüfsumme der empfangenen Nachricht korrekt, so wird ein das \texttt{NAK} bzw. \texttt{ACK} Bedienelement, bzw. \acs{SubVI}-Ausgang, auf \texttt{TRUE} gesetzt.  

% Daher muss für die Empfangene ACK-ACK Nachricht auf Empfängerseite, also im \acs{LabVIEW}-Programm, die Prüfsumme selbst erstellt und mit der erhaltenen verglichen werden. Das Empfangen einer ACK-ACK bzw. ACK-NAK Nachricht, sowie das Auswerten der Prüfsummen übernimmt das \texttt{UBX\_ACK.vi}.

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/UBX-ACK}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{UBX\_ACK.vi}}		%Bildunterschrift
	\label{pic:Blockdiagramm des UBX_ACK.vi}	%Referenz zum Verlinken
\end{figure}


\begin{table}
	\centering

	\begin{tabular}{|c|c|c|l|}
	\hline
		\textbf{Nachricht}	& \textbf{CLASS}	&	\textbf{ID}	&	\textbf{PAYLOAD-Inhalt} \\
	\hline
		ACK-ACK		& 05 	& 01 	& CLASS (Offset=0) und ID (Offset=1) der bestätigten Nachricht \\
	\hline
		ACK-NAK		& 05 	& 00 	& CLASS (Offset=0) und ID (Offset=1) der unbestätigten Nachricht \\
	\hline	
	\end{tabular}

	\caption{Aufbau der ACK-ACK und ACK-NAK Nachricht im UBX-Protokoll}
	\label{tab:Aufbau der ACK-ACK und ACK-NAK Nachricht im UBX-Protokoll}
\end{table}

\subsubsection{\texttt{\textbf{UBX\_readMsg.vi}}}	\label{sec:UBX_readMsg.vi}

Dieses \acs{VI} liest, wie Abbildung~\ref{pic:Blockdiagramm des UBX_readMsg.vi} zeigt,  eine UBX-Nachricht über die serielle Schnittstelle aus. Im ersten Teil (erster, blaue unterlegter Kasten in der Abbildung) werden die Startzeichen, auch SYNCH CHARACTER genannt, ausgelesen. Sobald diese empfangen wurden, werden im zweiten Teil (zweiter, gelb unterlegter Kasten in der Abbildung) sechs Byte plus die Länge der Nutzdaten ausgelesen. Damit ist die Nachricht komplett und es kann im dritten Teil (dritter, rot unterlegter Kasten in der Abbildung) überprüft werden, ob es sich um die erwartete Nachricht handelt. Außerdem wird hier überprüft, ob die empfangene Prüfsumme mit der anhand von \texttt{UBX\_CHKSUM.vi} selbst errechneten übereinstimmt. Sobald eine Nachricht mit korrekter Prüfsumme empfangen wurde, wird das \acs{VI} terminiert. Ansonsten wird weiter auf den Empfang einer Nachricht gewartet.  

\begin{landscape}

	\begin{figure}[htb]
		\centering
		\includegraphics[width=\linewidth]{img/UBX_readMsg}	%Breite und Pfad
	 	\caption{Blockdiagramm des \texttt{UBX\_readMsg.vi}}		%Bildunterschrift
		\label{pic:Blockdiagramm des UBX_readMsg.vi}	%Referenz zum Verlinken
	\end{figure}
\end{landscape}

Mit der Bestätigung des Kaltstarts seitens des LEA-6H ist die Initialisierungsphase abgeschlossen. Der \acs{GPS}-Empfänger wird nun einige Zeit invalide Daten empfangen, was aber wie in \ref{sec:Initiierung des Kaltstarts mithilfe des UBX-Protokolls} bereits erwähnt, unerheblich, wenn nicht wünschenswert ist. Das \acs{LabVIEW}-Programm wird dennoch nun in die Iterationsphase übergehen.  


\subsection{Iterationsphase}	\label{sec:Iterationsphase}

Nach der Initialisierung werden in der Iterationsphase die \acs{NMEA}-Protokolldaten mit Hilfe des von National Instruments zur Verfügung gestelltem \acs{VI}\footnote{Wie bereits in \ref{sec:initGPS.vi} beleuchtet, wurde die Initialisierung der Schnittstelle aus dem originialen \acs{VI} in ein seperates, nämlich dem \texttt{initGPS.vi} übertragen.} ausgelesen und in die Queue für das \texttt{LOGGING.vi} bzw. in den Melder für das \texttt{VIEW.vi} geschrieben. 

\subsubsection{\texttt{\textbf{readGPS\_LOOP.vi}} und \texttt{\textbf{VIEW.vi}} als Anlehnung an \texttt{\textbf{readgpstimepositionvelocity.llb}}}	\label{sec:readGPS_LOOP.vi und VIEW.vi}
Das Auslesen der seriellen Schnittstelle in \texttt{readGPS\_LOOP.vi} erfolgt hier noch sehr rudimentär. Es wird immer auf 1000 bytes gewartet und diese werden dann auf den \texttt{\$GPRMC}-String überprüft. Ist dieser enthalten werden die einzelnen Token, gemäß dem NMEA 0183 Standard ausgelesen und die resultierenden Daten der \acs{RMC}-Nachricht extrahiert. Da diese Umsetzung in Abschnitt~\ref{sec:readGPS_LOOP_v2.vi} noch einmal überarbeitet und dort auch genauer beschrieben wird, muss an dieser Stelle nicht darauf eingegangen werden. Es sei auf die \acf{LLB} \texttt{readgpstimepositionvelocity.llb} \cite{ninmea} verwiesen. Dieser Quelle entspringt auch die Grundlage des \texttt{VIEW.vi} Frontpanels.

\subsubsection{\texttt{\textbf{LOGGING.vi}}}	\label{sec:LOGGING.VI}
Wie eingangs erwähnt, werden die erhobenen Daten in \texttt{LOGGING.vi} in eine \acs{TDMS}-Datei geschrieben. Dieses \acs{VI} soll später komplett durch ein \acs{VI} zur \acs{SQL}-\acs{DB}-Kommunikation ersetzt werden. Daher wird nicht weiter auf diese Lösung eingegangen.






\section{Zeitdiskrete Messung über ein selbsterzeugtes, externes Triggersignal}	\label{sec:Zeitdiskrete Messung über ein selbsterzeugtes, externes Triggersignal}
\subsection{Hardwareumsetzung}	\label{sec:Hardwareumsetzung}
Um eine konstante Zeitbasis $dt_{ZB}$ zu generieren wird mit Hilfe des NI PXIe-6341 ein Signal mit einem festen Takt erzeugt. Die erzeugten Taktflanken werden vom selben Gerät gezählt um den aktuellen Wert $n$, der die Anzahl der gezählten Takte angibt, zu ermitteln, indem das Signal über ein selbst angefertigtes Y-Kabel, welches drei Enden besitzt, die Pins am NI PXIe-6341 des \acs{NF}-Systems, speziell der zugehörigen Anschlussbox, verbindet und ferner das Signal an \texttt{PFI 0} des NI PXIe-5450 im Slot 4 und 5, den \acf{BNC}-Triggereingang des \acs{URT} weiter gibt, wie in Abbildung~\ref{pic:Triggereingang am URT}\footnote{Die Abbildung zeigt das PLAYBACK-System, da für das RECORD-System die Triggerkarte fehlt.} zu sehen.
Tabelle~\ref{tab:Pinbelegung am NF-System} zeigt die verwendete Pinbelegung am \acs{NF}-System. Zur optischen Überprüfung des Taktsignals, wird ein myDAQ von National Instruments im Oszilloskopmodus verwendet. Dazu wird das Signal der Takterzeugung, also Pin~02, sowie die Masse vom Pin~36 an das myDAQ weiter gegeben. Um eine optische Überprüfung zu gewährleisten, so dass die Flanken für den Nutzer auch sichtbar sind, muss zunächst eine geringere Taktfrequenz, als die angepeilten 10~MHz verwendet werden.


\begin{figure}[htb]
	\centering
	\includegraphics[width=.7\linewidth]{img/TriggerURT}	%Breite und Pfad
	\caption{Triggereingang am URT}		%Bildunterschrift
	\label{pic:Triggereingang am URT}	%Referenz zum Verlinken
\end{figure}


\begin{table}
	\centering

	\begin{tabular}{|c|c|c|}
		\hline
		\textbf{Signal}	&	\textbf{Signalname}		&	\textbf{Pin Nr.}	\\ 
		\hline
		Takterzeugung	&	PFI 12 (\texttt{ctr0}) 	&	02 \\
		\hline
		Takteingang		&	PFI 0  (\texttt{ctr2})	&	11 \\
		\hline
		Masse			&	GND						&	36 \\
		\hline
	\end{tabular}

	\caption{Pinbelegung des NI PXIe-6341 am NF-System}
	\label{tab:Pinbelegung am NF-System}
\end{table}

\subsection{Softwareumsetzung}	\label{sec:Softwareumsetzung}
Für diese beiden Aufgaben der Takterzeugung und -zählung sind die \acf{DAQ}-Tasks \texttt{NF-HF-Taktausgabe} und \texttt{FlankenanzahlTask} im \acf{MAX} hinterlegt. Durch diese Vorgehensweise ist es einfach und an einer einzigen Stelle, nämlich im \acs{MAX}, möglich die Takterzeugung, wenn nötig, zu beeinflussen, ohne Änderungen am eigentlichen \acs{LabVIEW}-Programm vorzunehmen. So kann beispielsweise das $dt_{ZB}$ im Nachhinein angepasst werden. Zum Zeitpunkt der Implementierung wird zunächst eine Taktfrequenz von 10~kHz, also eine Periode von 100~us verwendet, wie Abbildung~\ref{pic:DAQmx Task zur Takterzeugung} zeigt. So kann mit dem myDAQ das Verhalten des Taktgenerators visuell überwacht werden, indem das myDAQ als Oszilloskop verwendet wird. \pdfmargincomment[style=todo]{das myDAQ in Testumgebung kurz erklären! Das kommt hier zum ersten mal!} %TODO das myDAQ in Testumgebung kurz erklären! Das kommt hier zum ersten mal!
 \pdfmargincomment[style=fixme]{ALLE Einheiten überarbeiten!} %FIXME ALLE Einheiten überarbeiten!
Da der Counter des myDAQ eine interne Basisfrequenz von 100~MHz und eine Basis-Taktgenauigkeit von 100~ppm aufweist \cite[S.~42]{nimydaq}, konnte auch ein $dt_{ZB}=100~ns$ also eine Frequenz von 10~MHz verifiziert werden. Bei dieser Taktgeschwindigkeit, ist aber die Liveüberwachung mit dem myDAQ als Oszilloskop nicht mehr umsetzbar, da der Nutzer die Flanken dann nicht mehr erkennen kann. Nach erfolgreichen Tests zur Verifikation der grundsätzlichen Funktionalität des Aufbaus, wird die Taktfrequenz auf 10~MHz gesetzt. Der nun verwendete Counter im myDAQ weist dabei auch über einen längeren Zeitraum von einer Stunde keine Abweichung vom ermittelten $n$ des \acs{NF}-Systems auf.  

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/TaktErzeugung}	%Breite und Pfad
	\caption{DAQmx Task zur Takterzeugung}		%Bildunterschrift
	\label{pic:DAQmx Task zur Takterzeugung}	%Referenz zum Verlinken
\end{figure}

Um den Hardwarezähler softwareseitig in \acs{LabVIEW} implementieren und anhand eines vorhandenen Sensors zu testen, wurde das Projekt \texttt{Kommunikation-LEA-6h.lvproj} erweitert und als \texttt{Kommunikation-LEA-6h\_CTR-Version.lvproj} gespeichert.
Dieses wurde um das \texttt{CTR\_FGV.vi} erweitert und das \texttt{readGPS\_LOOP.vi} durch die neue Version \texttt{readGPS\_LOOP\_v2.vi} ersetzt, wie in Abbildung~\ref{pic:MAIN.vi des Projekts Kommunikation-LEA-6H_CTR-Version} zu sehen ist. Die komplette VI-Hierarchie zeigt Abbildung~\ref{pic:VI Hierarchie des Projekts Kommunikation-LEA-6h_CTR-Version.lvproj}.


\begin{figure}[htb]
	\centering
	\includegraphics[width=0.7\linewidth]{img/main-LEA6CTR}	%Breite und Pfad
	\caption{\texttt{MAIN.vi} des Projekts \texttt{Kommunikation-LEA-6H\_CTR-Version.lvproj}}		%Bildunterschrift
	\label{pic:MAIN.vi des Projekts Kommunikation-LEA-6H_CTR-Version}	%Referenz zum Verlinken
\end{figure}


\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/ublxKommCTR_ViHirarchie}	%Breite und Pfad
	\caption{VI Hierarchie des Projekts \texttt{Kommunikation-LEA-6h\_CTR-Version.lvproj}}		%Bildunterschrift
	\label{pic:VI Hierarchie des Projekts Kommunikation-LEA-6h_CTR-Version.lvproj}	%Referenz zum Verlinken
\end{figure}


Die \acp{VI} \texttt{Einstellungen.vi} , sowie \texttt{LOGGING.vi} und \texttt{VIEW.vi} sind dem Projekt aus \ref{sec:Kommunikation mit u-blox Empfänger} entnommen und haben sich nicht oder nur marginal verändert, so dass auf sie nicht weiter eingegangen wird. Hinzugekommen ist in der Terminierungsphase das \texttt{TDMS-Viewer.vi}, welches lediglich das \texttt{TDMS - File Viewer.vi} von National Instruments aufruft, so dass die erstellte \acs{TDMS}-Datei direkt untersucht werden kann. Zum Zeitpunkt der Implementierung ist es bei häufigen Testläufen notwendig diesen Part deaktivieren zu können, weshalb sich dieses \acs{VI} in einer Diagrammdeaktivierungsstruktur\footnote{Mit einem Rechtsklick auf den CASE-Selektor kann das aktuell angezeigte Unterdiagramm de-/aktiviert werden. Dabei ist darauf zu achten, dass in einer Diagrammdeaktivierungsstruktur immer genau ein Unterdiagramm aktiviert sein muss.} befindet. 

Dem Referenzcluster wird in diesem Projekt eine Referenz auf ein Rendezvous, welches zur Schleifensynchronisation\footnote{Ein Rendezvous hat eine bestimmte Anzahl Teilnehmer. Diese Anzahl wird in der Initialisierung festgelegt. Alle diese Teilnehmer verwenden dann das \texttt{Wait at Rendezvous.vi} um aufeinander zu warten. Die Teilnehmer verbleiben so lang in dieser Warteschlange, bis sie vollzählig sind.} verwendet wird, die Referenzen auf die beiden \acs{DAQ}-Tasks für die Takterzeugung und Flankenzählung, sowie ein boolsches Element \texttt{Kaltstart ausführen?} hinzugefügt. Dieses boolsche Element wird im \texttt{Einstellungen.vi} beschrieben und deaktiviert ggf. die Ausführung des \acs{VI}s \texttt{UBX\_Kaltstart.vi} innerhalb des \texttt{init.vi}, was bei häufigen Testläufen während der Softwarevalidierung sehr hilfreich ist, da der Kaltstart mitunter einige Minuten in Anspruch nehmen kann.

\subsubsection{\texttt{\textbf{init.vi}}}	\label{sec:init.vi}
Dieses \acs{VI} entspricht überwiegend der in \ref{sec:Kommunikation mit u-blox Empfänger} vorgestellten Version. Abbildung~\ref{pic:Erweiterung des init.vi} zeigt die Neuheiten im Programm.  Hinzugekommen ist die Initialisierung des Rendezvous sowie ein neues \acs{VI} welches sich dem UBX-Protokoll bedient. Das \texttt{UBX\_NMEA-Konfig.vi} ist dem \texttt{UBX\_Kaltstart.vi} aus \ref{sec:UBXKaltstart.vi} nachempfunden und funktioniert gleichermaßen und unterscheidet sich nur im Inhalt der gesendeten Nachricht. Es sendet die Konfigurationsnachricht mit der \acs{ID} \texttt{01} und den hexadezimalen Nutzdaten \texttt{F004 0001 0101 0001}. Diese Nachricht konfiguriert den LEA-6H so, dass er die \acs{RMC}-Nachricht des NMEA 0183 Standard Protokolls auf beiden seriellen Schnittstellen UART1 und UART2, sowie der USB-Schnittstelle sendet. \cite[S. 115, f.]{LEA} Auf diese Weise wird auch ein anders konfigurierter \acs{GPS}-Empfänger der Produktreihe u-blox 6 GPS Modul so eingestellt, dass das Auslesen in der Iterationsphase funktioniert. Dies ist notwendig, da während der Validierung der Software verschiedene Empfänger verwendet werden, welche auf verschiedenen Schnittstellen, also \acs{COM}-Port oder \acs{USB}, kommunizieren.     


\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/ErweiterungInitCTR-Version}	%Breite und Pfad
	\caption{Erweiterung des \texttt{init.vi}}		%Bildunterschrift
	\label{pic:Erweiterung des init.vi}	%Referenz zum Verlinken
\end{figure}

\subsubsection{\texttt{\textbf{CTR\_manager.vi}}}	\label{sec:CTR_manager.vi}
Für den Umgang mit dem Taktgenerator und -zähler wird dieses Programm verwendet. Es entspricht nicht ganz den Entwurfsvorgaben des Referenzdesigns, da es einen Teil der Initialisierungsphase enthält und danach selbst in die Iterationsphase überleitet. Diese Architektur hat allerdings den Vorteil, dass es so für die Taktgenerierung und -zählung nur ein übergeordnetes \acs{VI} gibt. Dieses ist in Abbildung~\ref{pic:Blockdiagramm des CTR_manager.vi} dargestellt. Der rot unterlegte Bereich zeigt dabei den Teil des \acs{VI}s, der sich noch in der Initialisierungsphase abspielt. Dabei wird zunächst der Taktzähler mittels \texttt{CTR\_FGV.vi} gestartet. Anhand des Datenflussparadimgas ist sichergestellt, dass der Taktzähler auch wirklich läuft, bevor auf das Rendezvous gewartet wird. Als nächstes wird der Task zur Taktgenerierung gestartet. Innerhalb der \texttt{WHILE}-Schleife wird nun sekündlich auf den Benutzerabbruch gewartet. Sobald dieser eintritt werden zuerst der  Task der Taktgenerierung und danach der Task zur Taktzählung gestoppt. 


\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/CTR-manager}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{CTR\_manager.vi}}		%Bildunterschrift
	\label{pic:Blockdiagramm des CTR_manager.vi}	%Referenz zum Verlinken
\end{figure}


\subsubsection{\texttt{\textbf{CTR\_FGV.vi}}}	\label{sec:CTR_FGV.vi}
Diese \acf{FGV} \cite[S.~79]{viuLV} übernimmt die komplette Handhabung des Counters. Über dieses \acs{VI} wird der Counter gestartet, gestoppt und ausgelesen. Dabei kann entweder der aktuelle Counter-Wert gemessen ("`CTR messen"') oder der zuletzt von diesem \acs{VI} gelesene Wert ("`letzten CTR-Wert lesen"') ausgegeben werden, je nach gewählten Betriebsmodus.


Bei der Verwendung eines 10 MHz Takts wird der 32 Bit Counter des NI PXIe-6341 nach ca. 7~Minuten überlaufen, wie die Gleichung~\ref{eq:ctrUeberlauf32} zeigt. Daher ist es notwendig ein \acs{VI} zu implementieren, dass den internen 32 Bit Counter ausliest, die Zäherlüberläufe registriert und in einem 64 Bit Datentypen die detektierten Überläufe mit einrechnet und den korrekten Zählerwert abspeichert. Ein 64 Bit Zähler läuft erst nach circa 60.000 Jahren über, wie in Gleichung~\ref{eq:ctrUeberlauf64} gezeigt. Diese Umwandlung des 32 Bit Zählers in einen 64 Bit Zähler geschieht mit jeder Messung im \texttt{CTR\_FGV.vi}. 

\begin{equation}
	2^{32} \cdot 100~\text{ns} = 429,497~\text{s} = 7,158~\text{min} 
	\label{eq:ctrUeberlauf32}
\end{equation}
   

\begin{equation}
	2^{64} \cdot 100~\text{ns} = 1,844 \cdot 10^{12}~\text{s} = 59973~\text{a} 
	\label{eq:ctrUeberlauf64}
\end{equation}

Das \acs{VI} funktioniert nach dem Schema einer \acs{FGV} und speichert den ausgelesenen 32-Bit Wert des Counters im oberen Schieberegister. Wird im Betriebsmodus "`CTR messen"' ein neuer Wert gelesen, so wird dieser mit dem zuletzt gelesenen Wert verglichen. Ist der aktuelle Wert kleiner, als der zuvor gelesene, so muss es einen Zählerüberlauf gegeben haben. Die Berechnung des 64-Bit Werts in diesem Fall zeigt Abbildung~\ref{pic:CTR_FGV.vi Blockdiagramm}. Kam es nicht zu einem Überlauf, wird einfach die Differenz des aktuellen 32-Bit Werts und des im Schieberegister gespeicherten 32-Bit Werts auf den 64-Bit Zähler aufaddiert. Es ist also ersichtlich, dass das \texttt{CTR\_FGV.vi} mindestens einmal alle sieben Minuten ausgelesen werden muss, so dass ein Zählerüberlauf auch registriert wird.
Der Betriebsmodus "`letzten CTR-Wert lesen"' gibt einfach die Werte der Schieberegister aus. Das selbe geschieht im Betriebsmodus "`CTR stoppen"', während der Betriebsmodus "`CTR starten"' den Flankenzähler-Task aus dem Referenzcluster startet und direkt im Anschluss die erste Messung durchführt. Dabei werden beide Schieberegister mit dem aktuellen 32 Bit-Wert beschrieben.

\begin{landscape}

	\begin{figure}[htb]
		\centering
		\includegraphics[width=\linewidth]{img/CTR_FGV_BD}	%Breite und Pfad
		\caption{\texttt{CTR\_FGV.vi} Blockdiagramm}		%Bildunterschrift
		\label{pic:CTR_FGV.vi Blockdiagramm}	%Referenz zum Verlinken
	\end{figure}
\end{landscape}


\subsubsection{\texttt{\textbf{readGPS\_LOOP\_v2.vi}}}	\label{sec:readGPS_LOOP_v2.vi}
Zum Erheben eines möglichst realitätsnahen Zeitstempels beim Empfang einer seriellen Nachricht, liest diese neue Version nun ständig den Lesepuffer des \acs{COM}-Ports aus. Es wird dabei immer nur ein Byte gelesen, und dieses in einen eigenen \acs{VI}-internen Lesepuffer, einem String-Schieberegister geschrieben. Sobald ein "`\$"'-Zeichen gelesen wurde, wird \texttt{FGV\_CTR.vi} verwendet um den 64-Bit Counter Wert auszulesen, welcher später als Zeitstempel verwendet wird. Da immer nur ein Byte ausgelesen und der Zeitstempel direkt beim Empfang eines "`\$"'-Zeichens gesetzt wird, ist dieser so akkurat wie auf dem System erreichbar. \pdfmargincomment[style=todo]{Wie genau das ist und so weiter muss dann im Ausblick als Aufgabe für eine Verifizierungsarbeit beschrieben werden} %TODO Wie genau das ist und so weiter muss dann im Ausblick als Aufgabe für eine Verifizierungsarbeit beschrieben werden
Nach dem "`\$"'-Zeichen werden dann fünf weitere Bytes ausgelesen um zu überprüfen, ob es sich um eine der im CASE-Selektor definierten Nachrichten, wie beispielsweise "`\$GPRMC"' handelt. Ist dies der Fall, wird der erhobene Zeitstempel zusammen mit der nachfolgenden Positionslösung, in die \texttt{GPS-LOGGING-Queue} und dem dazugehöregen \texttt{GPS-VIEW-Melder} geschrieben. Letzteres wird allerdings nur durchgeführt, wenn die Nachricht tatsächlich vom Typ "`\$GPRMC"'  ist. Andererseits wurde nur der Anfang einer neuen NMEA 0183 Standard Nachricht empfangen. Wenn dies der Fall ist, muss dennoch die im Lesepuffer, welcher ausschließlich "`\$GPRMC"'-Nachrichten enthalten kann, zuletzt gespeicherte "`\$GPRMC"' Nachricht, respektive deren Positionslösung, geschrieben werden. 
Das Umwandeln der NMEA 0183 Standard \acs{RMC}-Nachricht übernimmt das \texttt{ReadStringToGPS-DATA.vi}, welches dem \texttt{readGPS\_LOOP.vi} in der vorherigen Version des Projekts aus \ref{sec:Kommunikation mit u-blox Empfänger} ähnelt und lediglich die gelesenen Token der Nachricht in, für \acs{LabVIEW} verständliche Datentypen, umwandelt und in einem Cluster zusammenfasst, welcher durch den zugehörigen \texttt{CTR}-Wert in \texttt{readGPS\_LOOP\_v2.vi} angereichert und dann in den Melder und die Queue geschrieben wird.

Der Rest des Projekts entspricht dem vorgestellten Schema aus \ref{sec:Kommunikation mit u-blox Empfänger}.

\begin{landscape}
	\begin{figure}[htb]
		\centering
		\includegraphics[width=\linewidth]{img/readGPSloopv2}	%Breite und Pfad
		\caption{Blockdiagramm des \texttt{readGPS\_LOOP\_v2.vi}}		%Bildunterschrift
		\label{pic:Blockdiagramm des readGPS_LOOP_v2.vi}	%Referenz zum Verlinken
	\end{figure}
\end{landscape}


\section{Synchroner Start via LAN-Steuerung des Slave-Systems}	\label{sec:Synchroner Start via LAN-Steuerung des Slave-Systems}
\pdfmargincomment[style=fixme]{t_0 als Zeitstempel nirgends hinterlegt. --> t_0 als Zeitstempel nicht wichtig, höchstens für Zuordnung der Dateien zueinander, aber Messfahrten weit auseinander. . .! Muss nur in realer Zeit synchron starten!} %FIXME t_0 als Zeitstempel nirgends hinterlegt. --> t_0 als Zeitstempel nicht wichtig, höchstens für Zuordnung der Dateien zueinander, aber Messfahrten weit auseinander. . .! Muss nur in realer Zeit synchron starten!
Wie in \ref{sec:Synchroner Startzeitpunkt} beschrieben, kann der synchrone Start des \acs{URT}s mit dem \acs{NF}-System realisiert werden, indem der Takt, welcher auch für die globale Zeitbasis verwendet wird, als Starttrigger am \acs{URT} genutzt wird. Dies kann auch händisch nachgewiesen werden, indem das \acs{URT} manuell hochgefahren und in den Trigger-Modus versetzt wird. Da bei einer Messfahrt möglichst nur ein System als Benutzerschnittstelle verwendet werden soll, wie Abbildung~\ref{pic:konzeptioneller Hardwareaufbau der Testumgebung} verdeutlicht, ist es notwendig das \acs{URT} über die remoteAPI fern zu steuern. Dabei wird die \acf{DLL}-Datei \texttt{URTRemoteCtrl\_Multi.dll} verwendet, welche sich auf dem \acs{NF}-System im Verzeichnis \texttt{C:\textbackslash urt\textbackslash bin\textbackslash} befindet. Die notwendigen Funktionen für das Setzen von Parametern und das Warten auf einen externen Trigger zeigt die Tabelle~\ref{tab:remoteAPI Nachrichten für das Warten auf einen externen Trigger}.


\begin{table}
	\centering

	\begin{tabular}{|c|l|p{5 cm}|}
		\hline
		1.	&	\texttt{\textbf{OpenControlSessionMulti()}} & Öffnen der Session \\
		\hline
		
		2.	&	\texttt{GPS1ChanWriteParametersMulti()} & Parameter setzen\\
		\hline
		
		3.	&	\texttt{RFRecorderWriteParametersMulti()} & Parameter für die HW-Kanäle schreiben, diese werden erst nach dem Aufruf von 4. gesetzt \\
		\hline
		
		4. &	\texttt{\textbf{RFRecorderSendRemoteControlCommandMulti()}} & übernehmen (RECALL) der Parameter, stoppt ggf. laufende Messung, kann auch für das Laden einer hinterlegten Konfigurationsdatei verwendet werden. \\
		\hline
		
		5.	&	\texttt{\textbf{CloseControlSessionMulti()}} & Schließen der Session \\
		\hline
		
	\end{tabular}

	\caption{remoteAPI Nachrichten für das Warten auf einen externen Trigger (nach\cite{URTrem})}
	\label{tab:remoteAPI Nachrichten für das Warten auf einen externen Trigger}
\end{table}

Zunächst muss eine Session geöffnet werden\footnote{Für alle jeden Signal-Generator muss eine eigene Session und eigene Konfigurationsdateien geladen werden. In diesem Beispiel wird dies nur exemplarisch am 1. Generator gezeigt.} (\emph{1.}). Dann können entweder alle Einstellungen für die jeweiligen Kanäle einzeln an das \acs{URT} weitergegeben werden (u.a. \emph{2.} und \emph{3.}), oder es kann eine Datei mit allen hinterlegten Einstellungen für die Kanäle geladen werden (\emph{4.}). Mit diesem Befehl werden alle auch alle Parameter übernommen, die in \emph{2.} und \emph{3.} gesetzt wurden. Das Warten auf einen externes Triggersignal ist ebenfalls eine Einstellung. Die Messung wird beendet, wenn die entsprechende Session wieder geschlossen wird (\emph{5.}).
Wenn alle Einstellungen in einer Konfigurationsdatei auf dem \acs{URT} hinterlegt sind, können Schritt \emph{2.} und \emph{3.} ausgelassen werden. Diese Herangehensweise ist in Abbildung~\ref{pic:Blockdiagramm des MAIN.vi im Projekt LV-remoteAPI} zu sehen. 

\begin{figure}[htb]
	\centering
	\includegraphics[width=\linewidth]{img/urtREM}	%Breite und Pfad
	\caption{Blockdiagramm des \texttt{MAIN.vi} im Projekt \texttt{LV-remote\_API}}		%Bildunterschrift
	\label{pic:Blockdiagramm des MAIN.vi im Projekt LV-remoteAPI}	%Referenz zum Verlinken
\end{figure}

Der Ablauf im \texttt{MAIN.vi} des Projekts \texttt{LV-remote\_API.lvproj} ist wie folgt.
Zunächst wird im \texttt{Start.vi} der Nutzer aufgefordert die Pfade der Konfigurationsdateien für das RECORD und das PLAYBACK-System anzugeben\footnote{Diese wären in einem finalen Projekt fest vordefiniert, da sie sich zur Laufzeit auch zwischen verschiedenen Messungen wahrscheinlich kaum ändern werden. Auch eine Auswahlmöglichkeit aus verschiedenen möglichen Konfigurationsdateien wäre denkbar.}. 
Auf dem \acs{URT} sind das die Dateien \texttt{rt\_playback.cfg} und \texttt{rt\_recorder.cfg} im Ordner \texttt{urt\textbackslash tstCfg} des \acs{URT} mit der IP Adresse \texttt{192.168.1.11}. Der Inhalt dieser Dateien kann sich ebenfalls angesehen werden. Da dies alles über die remoteAPI nicht möglich ist, muss die Pfad-Palette in \acs{LabVIEW} verwendet werden. Dafür müssen das \acs{NF}-System und das \acs{URT} im selben Netzwerk sein und der genannte Ordner muss für das \acs{NF}-System freigegeben sein, so dass von \acs{LabVIEW} aus darauf zugegriffen werden kann.

Da das \texttt{Start.vi} ggf. ohne \acf{LAN}-Kommunikation mit dem \acs{URT} beendet wurde, wird das \acs{URT} danach angepingt (\texttt{pingDevice.vi}). Sofern dies fehlerlos funktioniert wird die \acs{URT}-Version als Überprüfung der Kommunikation ausgelesen (\texttt{URTVersionAuslesen.vi}) und im \texttt{MAIN.vi} angezeigt. Erst jetzt beginnt der in Tabelle~\ref{tab:remoteAPI Nachrichten für das Warten auf einen externen Trigger} beschriebene Ablauf.

Die Session wird mit dem \texttt{URT\_PB\_OpenCtrSssnMlt.vi} geöffnet. Dabei wird die \texttt{URTRemoteCtrl\_Multi.dll} in \acs{LabVIEW} verwendet. Für alle Parameter der Funktionen, auch wenn es Zeiger sind, muss eine Konstante oder anderweitig ein Wert in \acs{LabVIEW} hinterlegt werden, damit die Funktion aufgerufen werden kann, sonst ist das \acs{VI} aufgrund des fehlenden Datenflusses nicht ausführbar. Wichtig ist also in diesem \acs{VI} nur, dass die Hardware Instanz auf 1 gesetzt wird, um den ersten Signal-Generator anzusprechen \cite[S.~219]{URTrem}. Nach dem Öffnen der Session wird überprüft, ob die gewählte Konfigurationsdatei für das PLAYBACK-System vorhanden ist. Ist dies der Fall (\texttt{TRUE}-Case der ersten Case Struktur), wird diese Konfiguration in \texttt{URT\_PB\_ConfigLaden.vi} mit dem \texttt{RFRecorderSendRemoteControlCommandMulti()} Befehl geladen und das \acs{URT} \emph{scharf} geschalten, da es fortan auf den externen Trigger wartet. Dass dies funktioniert kann nachgewiesen werden, indem parallel das Projekt \texttt{Kommunikation-LEA-6h\_CTR-Version.lvproj} gestartet und ausgeführt wird. Beide Projekte zusammen starten dann ihre Messungen gleichzeitig zum Zeitpunkt $t_0$ und mit aufgrund der globalen Zeitbasis $dt_{ZB}$.

Nach Beenden der Messung, hier nach 10 Sekunden, wird die Session geschlossen (\texttt{URT\_PB\_CloseCtrSssnMlt.vi}) und somit der Messvorgang beendet.

Damit das System beim Hochfahren auch die remoteAPI startet, muss in \texttt{C:\textbackslash urt\textbackslash bin\textbackslash \acs{URT}-BOOT-SETTING.ini} die Option \texttt{Auto-Remote = on} gesetzt werden. Dies bringt auf dem \acs{URT} leider nicht das erhoffte Ergebnis, das \acs{URT} antwortet nach dem Hochfahren nicht automatisch auf die Befehle des \acs{NF}-Systems. Das Einfügen einer Verknüpfung zur Datei \texttt{C:\textbackslash \acs{URT}\textbackslash \acs{URT}\_VERSION.exe} in den Autostart-Ordner schafft Abhilfe bei diesem Problem.